B站大数据质量务实

本期作者

郭跃鹏

软件工程师

01 背景

数据质量是基于大数据衍生的应用有效与否的重要的前提和保障之一。为了能在大数据上面孵化出更加有深度，更加有竞争力的应用，以及B站高速发展的业务都需要我们数据平台能提供实时的，准确的，可以被信赖的数据。

而另一方面，数据平台要向终端用户提供可以信赖的数据，又依赖于整个数据加工链路环境的稳定迭代和健康发展，这涉及到数据平台模型本身的质量，业务调度的可靠，资源调度的高效，以及各种执行引擎的高效协作等等，最后所有这些大数据基础组件的稳定又离不开PAAS, IAAS等基础服务的稳定。

总之，可信赖的数据质量是大数据平台核心竞争力的体现，是大数据航母战斗群的预警机。数据质量团队的背后是大兵团级别的组织、协作和保障工作。数据质量的高可信度依赖于业务模型团队，数据质量平台，业务调度团队，计算引擎团队，和各种存储和搜索查询引擎等兄弟舰队通力合作和鼎力支持。

02 目标

快速发现和修复问题是我们大数据质量团队的使命。

我们有接近1亿的日活用户依赖于我们的数据，为了服务于这些用户，我们每天有30w+的任务处理40PB左右的数据，实时管道每天消费处理6万亿条的事件和日志，为了杜绝用户用错数据的风险，经过我们持续迭代，分阶段，我们逐步的实现了如下三个子目标。

流程化

流程化不是一句空洞的口号，是我们长期被事故狂轰乱炸后的经验的总结，是一条行之有效的解决问题的办法。通过流程化，对于一些容易出事故的隘口，定义一些标准的流程SOP，让运维同事对照SOP可以准确无误的上线操作和监控。

流程化挑战的地方很多，如如何在复杂的业务中设计出来一套成熟的流程，能全面而且稳定地解决问题。如如何监控我们的系统，到底监控哪些指标？都是需要团队仔细思考和打磨的。

最后，流程化接入的成本也要在设计时仔细考量，因为业务千差万别，如何做到业务方接入低成本或者无成本，这对我们的设计的易用性和可扩展性提出来很高的要求。

自动化

如果说流程化是对B站人工运维场景的总结，那自动化就是对这些运维场景的工业化，自动化让我们彻底的离开了手工时代。这对我们的设计的全面性，兼容性，以及稳定性都提出来更高的要求。

智能化

智能化是运维迈向自由之路的必然选择，在数据量大，场景多，容易出故障，人员经验不足的情况下，智能化对我们的设计提出来与时俱进的新要求。

03 理论与实践

数据质量问题是一个大家都非常关注的问题，也正因为数据质量利益方多，管理和沟通容易陷入各说自话的困境。为了避免沟通时无的放矢的困境，我们先正本清源，对数据质量问题具体化，概念化。

数据质量可以从很多方面来量化，我们结合B站自身的实际，我们将数据质量问题限定为以下几类。

• 完整性

  数据是否完整，主要现象为表的条数是否有丢失。

• 唯一性

  考察的数据集里面是否有数据重复，这个分全量粒度和增量分区粒度。

• 时效性

  数据可用性的时间维度的要求，这点相信大家对实时数据感受比较明显，但离线也有时效性问题。

• 准确性

  数据是否按照符合预期的逻辑在产出，如身份证，年龄逻辑上是否自洽。

• 一致性

  两个数据源之间的数据是否一直，如sum(A.b where A.c ='Shanghai') = sum(B.b)

以上划分不一定存在完美的正交划分。一个具体的质量问题，可能既有一致性的特征，也有准确性的特征。数据质量问题本身就是这样，不是非此即彼的划分。我们不必陷入形式主义的困扰。

通过上述标准，让不同的利益方沟通更加有效，让我们能快速落地数据质量目标，是我们设立这个标准的目的。

 3.1 数据质量理论

技术的驱动是需求，大多数用户的需求大概是这样子的：

“当我的业务数据，今天的条数的波动大于30%的时候，请给我打电话告警。”

不论各个团队什么场景，怎么表述，需求的表象千差万别，经过我们数据质量团队的经验总结(Copyright)，用户的数据质量需求已经被高度抽象为技术上的三段式：

 3.1.1 数据质量模型

针对高度抽象的需求，我们的整体技术架构设计如下：

架构中重要的工作流如图紫色部分所示，一个数据质量问题，我们将它抽象成一个workflow，拆解为三个子stage 。

Recording

获取需要监控对象的数据质量特征，如表条数这个指标。

对于Recording，它的设计面临的挑战之一是，按照业务的场景，我们的监控对象会驻留在各种不同的异构数据源里（Hive, Mysql, Kafka, Hudi, OLAP等等）。这就要求我们，一方面要统一的抽象出这个监控对象，另外一方面，我们需要兼容支持不同的数据源是异构的这个现实。

第二个挑战是Recording的结果是什么？不同的场景对于这个结果有不同的诉求。我们数据质量平台经历了多次迭代，如对不同需求CaseByCase的处理而后续难以维护和升级等，找到了一套标准来抽象Recording。

那就是，一方面，这个监控对象的数据质量特征必须是可量化的。第二个，对于数据平台来说，这个量化最好是用类SQL的语法来表达监控对象的数据质量特征。

通过这套标准，我们能最快速的迭代用户的需求，也能让不同的利益方理解并跟踪大家的诉求。

经过多次迭代，我们沉淀出150+中的典型数据质量特征，我们把这些特征做成典型标准库，以便用户能快速选择适合自己场景的数据质量标准。

另外一方面，在查询这个特征的时候，我们需要兼容异构的数据源，我们抑制了自己再造轮子的冲动，充分利用开源的框架来connect到不同的异构数据源。

我们目前支持的可以被检测的数据源包括但不仅限于：

• Hive

• Mysql

• Iceberg

• Clickhouse

• kafka

• Hudi

最后，由于数据平台的环境的多元性，我们有很多场景的数据源是不容易通过数据质量平台connect 连通的。

这个问题可以通过push gateway来解决的。用户需要在数据质量平台注册一次，注册这个指标的含义，后续客户端就可以把数据质量特征通过push gateway推送到数据质量平台，后续的检查告警就会被数据质量平台包圆了。

Checking

判定这个指标是否满足告警的条件，如M<100。

对于Checking，一方面也为了满足不同用户定制化的需求，另外一方面为了重用已经存在的数据质量指标，节省算力。对于Checking，我们设计了一套丰富的DSL来定义数据质量指标，如max，min，平均值，以及加减乘除等算子。例如我们需要两个维度指标的和和汇总指标的比例不超过30%，可以通过如下DSL来表征。

结合B站自身的用户行为特征，我们也相应的定制开发出来一些周同比，日环比，多日平均等DSL来快速支持用户的需求。

Alerting

判定M<100这个条件成功，给xxx打电话告警。

对于Alerting，其目标是将告警这个消息exactly once 发送到当事人。

Exactly once 有两个角度。

第一个角度是人的角度，如果一次故障，重复报警，会让一二线运维开发人员应接不暇，不能安心高效地处理故障。反之，如果一次故障，告警漏报，也是灾难性的，会造成大量的事后沟通和恢复成本。

第二个角度是故障的角度，一次故障能同时导致大量的告警，因为我们大数据组件之间的依赖关系更加复杂和隐藏，这种复杂性会成比例放大告警，将次生告警和真正的告警无区别地骚扰用户。

告警Exactly once 需要 RCA(Root Cause Analysis)的分析，将根本原因推送给用户，而不是大量的没有经过加工的告警，风暴式轰炸用户。

根因分析 

根因分析困难在于以下几点：

• 操作的复杂性，业务团队技术栈的多样化，细粒度的服务化和组件化，这些多样化的领域知识让中心化的值班运维团队难以应付。

• 大量告警有可能同时出现在不通的服务和组价中间，根因分析需要解决这些告警之间的因果关系。

• 大量散落的log，metrics，和trace都有可能是根因之一。

根因分析一般有两种主流派，一种是基于机器学习的根因分析，一种是基于图的根因分析。

但我们由于缺乏大量的训练数据不适合推进机器学习方法，而选择了如下的基于图的根因分析方法。

我们的处理流程如上图所示，整体大概分为三个阶段。

第一，基于任务依赖或者其他的trace信息，构造任务级别的依赖图。

这个任务(组件)基本的依赖图是动态更新的（T+1）。

第二，在任务级别的依赖图的基础上，丰富metrics异常事件，日志异常事件或者发布记录等“事件”来构造事件因果图。

因果图基于任务依赖图的子集，初始状态是一个窗口期内，那些告警的组件和一个扫描半径内（可配置）的所有组件。

我们定义了通用的事件模型（type, event_time, domain, owner, resource_uri, properties）。

平台和运维人员可以根据场景来裁剪和丰富这个根因图，例如下游的延时事件可能需要和上游的延时事件关联起来。

attach job(id=123) with modelrelease_event('update dimension...');
connect job(upstream).latency_event with job(downstream).latency_event;
connect job(upstream).completeness_event with job(downstream).consistency_event;
disconnect job(sparkversion=2.1).failed_event with spark(v=2.1).release_event;
connect job(sparkversion=3.1).failed_event with spark(v=3.1).release_event;

第三，Root Cause Ranking算法，经过多次迭代给出可能的根因列表。

基于更加精确的事件级别的图，和通用的PageRank算法类似，我们在这个带权重的图上迭代出根因。

 3.2 数据质量实践

 3.2.1 任务调度问题

对于数据质量平台来说，调度的目标是最快的触发数据质量的检查任务。

对于数据质量检查时机的要求，如果检查太早了数据还没有准备好，就会因为脏读或者不可重复读而误告警。而数据质量检查时机太晚，对于重要的业务来说，如果有数据质量问题，随着时间的推移，故障处理的成本会剧增。所以调度数据质量任务的时机是非常重要的。

我们的调度策略分两种，一种是基于事件的调度策略。

对于一份数据，数据是有生命周期的，如数据定义，数据产出，数据可见，数据上线，数据归档，数据销毁。

如果任务已经产出完成，我们数据质量平台会和作业调度系统集成，在作业完成的那一时刻，数据质量平台会立刻触发数据质量特征的采集和检查。

如果数据检查出质量有问题，对于重要的场景，我们会熔断后续的数据加工链路，直到上游的数据质量满足需求为止，下游的任务才能开始启动。

另外一种调度策略是基于时间窗口的调度策略，对于流式数据的近实时监控，我们基本都采用这种策略。

但我们的任务量大，检查的频率要求细，调度系统如何保障高可用性，低时延，可弹性，也是一个挑战性的问题。

我们调度系统的架构如下：

在实践的过程中，我们也出现了大量任务抢占资源的问题，影响整个调度系统的吞吐率。

我们按照业务特征和历史行为，设计了不同的队列来隔离不同的请求，也可以按照配置来整体响应降级，以便保障系统的高可用性。

 3.2.2 来源异构问题

在落地数据质量平台的过程中，我们遇到了很多的异构的数据源。虽然大多数数据是来自于HDFS上面，也有很多数据来自于其他不同的介质。这些主要取决于用户的场景，有的来自于业务库mysql，有的来自于查询加速层如OLAP。

对于不同catalog的数据源，数据质量平台利用了开源的计算引擎各种connector的能力，来connect不同的数据源。对于不通的数据源，也可以根据SPI定制connector。

在具体实践的过程中，也要和传统DB层打通，如DAL层逻辑表和物理表的映射。

对于业务库的读的限流也要在调度中有所考虑和监控。

 3.2.3 规则覆盖问题

数据平台每天有30w+的任务，业务线涉及到B站业务的方方面面。传统的人工一个表一个表的地推覆盖是难以为继而且不现实的。

我们采用了业务线的线性方式来自动化规则覆盖，在我们数据质量工具平台，我们可以批量的拉起一条业务线的所有表来配置一些非常重要的规则。

我们数据质量平台提供了150+个规则，但是，用户的需求永远在路上，为了第一时间满足用户的需求，我们平台保持了规则的开放性，用户在满足规范的约束的前提下，可以通过自定义规则来快速迭代。

 3.2.4 智能覆盖问题

即便人工可以覆盖很多重要的业务线，对于业务的理解程度也是配置告警的一个难点，尤其是对于固定阈值的选择更是我们用户遇到的一个两难问题。如果阈值过于敏感，就会出现误告警，如果阈值过于迟钝，就会出现漏告警。

为了解决这个难题，基于时间序列数据我们开发了一套智能监控系统。用户可以只定义指标，不设置告警阈值，智能监控系统来自行判断哪些数据是异常的行为。

如图所示：

我们将这段时间序列数据拆解成几个组件，趋势 + 周期 + 节假日 + 噪音， 如下图所示：

通过这个智能阈值，我们能做到比用户更懂数据，因为预测模型可以综合考虑业务的趋势，业务的周期性，突发事件，节假日等因子。

通过上了这个模型之后，我们的用户的配置告警的压力大为减轻。

举个例子，我们通过这个模型对用户投诉评论行为进行了预测：

我们发现了如下几个特征：

第一，投诉评论的趋势在缓慢下降，说明了我们的社区越来越健康，越来越充满正能量。

第二，在09.10前后几天投诉明显增多，可能有什么突发事件在这几天发酵，这可以让业务同学有机会调查，进一步去规避社区评论的一些风险。

第三，投诉评论行为每周二是一个高发期。

在我们实践的过程中，数据质量平台也遇到了一些预测效果不理想的问题，原因是多方面的，我们也做了很多工作来提高预测的准确性。如：

• 故障事故等噪音的清洗，如果系统中频繁发生故障，系统里面会有一些噪点，我们把这些噪点通过事故处理一起处理掉。

• 变更的管理，例如业务模型的升级，这些change point对预测是有影响的，我们模型也把这些信息都集成进来处理。

• 丰富我们的模型库，对于不同的业务，评测模型并选择最优的预测模型。

 3.2.5 告警实践问题

在落地数据质量平台的过程中，如何提升用户的体验，快速准确的告警一直是我们追求的目标。

数据质量告警是链接代码、配置和生产环境的桥梁，在告警的信息中，多一些有用的context，少一些噪音在实践中一直需要迭代演化的。

数据质量的告警很多都发生在夜晚，我们将告警的信息送到移动端，让用户可以快速预览告警的信息。

告警的通道也是多渠道的，用户可以选择合适的方式来获取告警信息，如电话，短信，邮件，微信等。

基于值班系统，我们把告警第一时刻通知给值班团队。

 3.2.6 全链路之监控

不谋全局者，不足谋一域。

单个网格的数据质量没有问题，不一定意味着全链路的数据没有问题。局部的视角天然是有局限性的，我们需要从全局的视角，业务的链路视角来监控。

例如，对于时效性而言，数据对最终用户可见出现了晚点，这个也不是优化局部一个任务能解决的问题，这个尤其需要从链路的视角来进行定位时效的瓶颈在哪里？哪些模型任务变成了关键链路(Critical Path)上的任务？

再如，如果一个任务出现了故障，到底影响了哪些业务，运维同学都需要从链路的全局角度来整体地评估故障的影响和严重程度，以及待办项的轻重缓急。

为了这个目的，数据质量平台开发出了整个任务生产加工链路的监控视图，方便运维人员能全局的高度看问题。

通过这个视图上，运维人员还可以了解到：

1. 关键链路，如上图的蓝色链路所示。用户后续也可以通过这个关键链路进行模型优化和升级。

2. 数据加工链路现在加工到哪个环节，故障出现在哪个环节？预计还要多久可以产出最终数据。

3. 时效性，链路叶子节点完成时间的预测，参考TCP RTO，我们实现了链路完成时间的预测，经过这个智能预测算法，我们时效性这个维度的告警准确性提升到了95%。

4. 数据加工链路目前出现了哪些告警？哪个模块的同学正在解决，影响是什么？通过链路视图可以快速查看。

04 经验和教训

流程化先行，工具化次之，智能化是最后实现无人值守的必由之路。

链路需要向左向右打通，能实现链路真正的端到端打通。

通过算法，来自动学习数据的特征，从而自动覆盖特征质量的监控。

方案的取舍需要考虑隐形成本，尤其是长期的运维成本。

运维的思路是现在就解决问题，解决现在的问题。

05 未来的规划

智能化

目前我们阈值的配置是智能化的，但给定一个表或者一列，用什么规则还是依赖人工经验判断的。这种低效的人工的操作也很大程度上影响了我们的数据质量的覆盖率。后续我们会开发数据的智能分析工具，对表或者列做深入的分析后，能自动发现数据的业务分类、类型、格式等等后存入catalog，基于这些信息，对目标数据集自动应用恰当的规则来保障数据质量。

实时化

在流批一体的大背景下，这些都需要一个快速高效的实时质量方案。

由于实时本身的特征，上文类SQL的DSL因缺乏动态性，扩展性目前是不能高效解决实时数据质量问题的。

我们后续将会和实时团队一起更好地覆盖实时数据质量问题。

故障修复

自从Google 三论文引领大数据的新时代以来，大数据社区，大量的分布式系统因为其弹性扩缩容, 分治，容错，标准的数据处理流程等优势而得到快速发展。

但不可否认的是，大数据系统也伴生着故障修复的困难，这个是大数据平台亟待解决的一个重大问题。

即便是一个微小的代码或者配置错误，也会带来整个数据平台的不可用，而造成灾难性的后果。

后续也敬请关注我们的故障修复自动化平台，如何对故障的生命周期进行全覆盖？

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，请给我们点个赞吧！

---